|
Group: Forum Members
Posts: 13,
Visits: 81
|
Hi Tim Not sure where to post this, so I'll put it here. Problem
I exported a flight log to GPX and imported it elsewhere. I noticed some very bizarre behaviour in the 'elsewhere' with particular respect to the aircraft's groundspeed. Cause
I traced the problem down the .flightlog files themselves. It wasn't hard to work out the format for the file. Regard the following: 26000,N513245.45 W0010622.95,191.4,93.8,324.5,239.3 29000,N513240.75 W0010623.55,177.1,95.4,361.9,301.7 30000,N513237.65 W0010622.85,172.0,95.0,378.3,344.2 31000,N513237.65 W0010622.85,167.1,96.6,395.7,344.2 31000,N513236.05 W0010622.20,167.1,96.6,413.4,367.2 32000,N513236.05 W0010622.20,167.1,96.9,413.4,367.2 34000,N513233.10 W0010620.25,153.2,97.0,448.5,424.5The first field is the number of milliseconds that have elapsed since the START= field at the file header. The rest is positional & velocity information. Consider lines 3-6. Between 30 and 31 seconds of flight, the aircraft apparently doesn't move (same position) despite the track and GS information suggesting differently. Then there is a second 31 second point logged at a different location, before a 32s point at the same location again. SolutionNot sure why this is occurring but clearly duplicate entries are creating issues not present when within the SD environment. I manually deleted the duplicate entries after manipulating a .flightlog in Excel and the results after exporting to GPX were better but not entirely fixed, probably because it isn't always the second row of duplicate data which is wrong. Also...
While investigating this, I realised why some of my flightlogs are from 2005 (!). The #START= field seems to use the system time of the recording unit to generate the timestamp. Why? We are using SD with GNSS navigation which is, in fundamental terms, a time-based navigation system!! Why not switch to using GPS time to generate the #START field? That way flightlogs will always show accurate dates & times even if, for example, I need to change the battery in my iPaq halfway through a days flying... #START=20050301110825
I fly something quick, but not time-machine quick... 
|
|
Group: Forum Members
Posts: 8.1K,
Visits: 9.4K
|
The .flightlog format is designed to be very simple, just dumping raw GPS data to the file every X seconds. It can miss a dump if the iPad is busy doing something else, or has been put to sleep by the user.
A flightlog can be started whether or not there is a GPS fix, and the GPS fix can easily be lost while logging. That is why we cannot use GPS time in the flightlog format.
I'm not really sure what the solution is to your problem. I don't see the SkyDemon behaviour as a bug as described.
|
|
Group: Forum Members
Posts: 13,
Visits: 81
|
Thanks for the explanation. The timestamp thing, well, ok. Yet by saying that the software dumps simple, raw GPS data and then going on to say that since the signal can be lost it can't use GPS time to timestamp that data, I'm left confused. It suggests that it isn't dumping 'raw' GPS data at all, but Skydemon's interpretation of that data, which can be erroneous as we've seen. The bigger issue is not that it might 'skip' a dump, the issue is more that it has dumped reports for two different positions at exactly the same point in time (lines 4 and 5 in the list I gave) and then the same position in space at two different points in time (lines 5 and 6). Clearly the first is physically impossible and the second only possible in a hover so, hence, surely a bug...? Or, if this is truly by design, it's poor design. That was the gist of my post. Having exported a log from Skydemon into GPX format, the first record I get is: <trkpt lat="51.553030" lon="-1.099361"><ele>61.1124</ele><speed>16.925223</speed><time>2005-03-01T06:42:04Z</time></trkpt>2005? Only because I might have had to change my iPaq battery halfway through a long flying day. This record is only 'accurate' as long as the timestamp at the start of the .flightlog file it was exported from is correct. Since the latter is based on the system time of the recording unit, there is no integrity. Slightly poor show when you have a perfectly valid and accurate indicator of Zulu time at the hub of your navigation software; GNSS signals. Not only that, but the time shows in 'Z' format when it isn't. If the recording unit (iPaq, laptop, Ipad, whatever) is in a different timezone or has daylight savings time applied, the timestamp at the start of each SD log is wrong. So to then export it as a 'Z' time in a GPX file is not really legit. Memory-Map, meanwhile, may not warn about NOTAMS or give an ETA at the next waypoint, but at least it exports data with integrity. A similar GPX export gives a point for <trkpt lat="51.5534233093" lon="-1.0992983341"> <ele>67</ele> <time>2013-08-04T15:18:05Z</time> </trkpt> Seemingly a higher level of accuracy, a timestamp that was obtained from the GPS signal rather than the recording unit and is therefore immune to system time errors, timezone settings or daylight savings, as several years of my using it has demonstrated. I digress. Why not just have a .flightlog file which stores truly 'raw' GPS data; GPS time, GPS latitude, GPS longitude, GPS elevation, at intervals as frequent as you might like?
If SD loses a GPS signal, I don't see what useful data it could be logging from it anyway unless it starts doing some kind of ded-reckoning calculations.
|
|
Group: Forum Members
Posts: 8.1K,
Visits: 9.4K
|
SkyDemon already stores raw GPS data in the flight log: latitude, longitude, speed, altitude and track. It does this in a format where the first column is the number of milliseconds since the flight started. The start date/time of the log is marked (in UTC) as part of the filename and in the first line of the file. Although we may design it slightly different today if we were starting fresh, there is nothing inherently wrong with the format.
You are looking for a completely raw GPS data log. SkyDemon stores flight logs, a large part of which is raw GPS data. Relying on correct system time in a modern device is not unreasonable. We have a facility for exporting to GPX format, and it does the best it can when performing such an export. The data points exported should be one to one with the SkyDemon format, as far as I can recall.
I am unsure why the number of milliseconds is apparently being rounded, I will check into that.
|
|
Group: Administrators
Posts: 48,
Visits: 212
|
What device produced the log you're referring to in your first post, please?
|
|
Group: Forum Members
Posts: 538,
Visits: 2.2K
|
It seems to me that the data FORMAT is perfectly fine. It's how you derive the actual data that get's me scratching my head. The time information contained in the START item ought to be taken from the GNSS system; it is more accurate, automatically reflects zulu time and is resistant to erroneous clock settings. The elapsed milliseconds I would calculate as the difference in GNSS times of each fix and the START time. Anything else appears to me less robust and error prone. It might be for other reasons, though, that it was done that way. But one can always improve, right?
-- Chris.
|